
%\begin{figure*}[ht]
%    \centering
%    \vspace{+5pt}
%        \includegraphics[width=5.5in]{testcase-pep.eps}
%       \vspace{-4pt}
%    \caption{\label{fig:testcase-pep} Test case code and PEP code examples}
%   \vspace{-10pt}
%    \vspace{+3pt}
%\end{figure*}

\begin{figure}[t]
  \centering
     \includegraphics[width=2.5in]{testaugument.eps}
    \vspace{-4pt}
 \caption{\label{fig:testexecution}Evaluation process of XACML policies in a policy-based software system.}
  \vspace{-10pt}
 \vspace{+3pt}
\end{figure}
  
\section{Background}
\label{sec:background}

Our approach is based on 
%This section presents the background information for policy-based software systems and XACML policies.
%\subsection{Policy-based Software Systems: PEP-PDP separation}
%Access control policies can be specified in many languages like EPAL \cite{epal} or XACML \cite {oasis05:xacml}. 
%In this paper, we focus
policy-based software systems regulated by policies specified in XACML \cite {oasis05:xacml}.
XACML has become the de facto standard for specifying policies.
%Such policy-based software systems 
%XACML policies are specified separately from actual functionality (i.e., business logic).
Typically, XACML policies are specified separately from actual functionality (i.e., business logic) in program code.
Figure~\ref{fig:testexecution} illustrates evaluation process of XACML policies.
At an abstract level, program code interacts with policies as follows.
Program code includes security checks, called Policy Enforcement Points (PEPs), to
check whether a given subject can have access to protected information.
The PEPs formulate and send an access request to a security component, called Policy Decision Point (PDP) loaded
with policies. The PDP next evaluates the request against the policies and determines whether the request should be permitted or denied. Finally, the PDP sends the decision back to the PEPs to proceed. 


\begin{figure}[t]
    \centering
        \includegraphics[width=3.3in]{example_policy.eps}
        \vspace{-12pt}
    \caption{\label{fig:example}An example policy specified in XACML.}
    \vspace{-10pt}
%    \vspace{+3pt}
\end{figure}

%\begin{figure*}[t]%{t}
%\begin{figure}[firstnumber=100]
%\begin{CodeOut}
%\tiny % Too samll
%\begin{alltt}
% 
% 1 <Policy PolicyId="\textbf{Library Policy}" RuleCombAlgId="\textbf{Permit-overrides}">
% 2  <Target/>
% 3    <Rule RuleId="\textbf{1}" Effect="\textbf{Permit}">
% 4      <Target>
% 5        <Subjects><Subject> \textbf{BORROWER} </Subject></Subjects>
% 6        <Resources><Resource> \textbf{BOOK} </Resource></Resources>
% 7        <Actions><Action> \textbf{BORROWERACTIVITY} </Action></Actions>
% 8      </Target>
% 9	    <Condition>
%10        <AttributeValue> \textbf{WORKINGDAYS} </AttributeValue>
%11      </Condition>
%12    </Rule>
%...
%35 </policy>
%\end{alltt}
%\end{CodeOut}
%\vspace*{-3.0ex} \caption{An example policy specified in XACML}
% \label{fig:example}
%\end{figure*}

%XACML (eXtensible Access Control Markup Language)~\cite{oasis05:xacml} has become the de facto standard
%for specifying policies. XACML is standardized by the Organization for the Advancement of Structured Information Standards (OASIS).
An XACML policy consists of a \Intro{policy set}, which further consists
of \Intro{policy sets} and \Intro{policies}. A \Intro{policy} consists
of a sequence of \Intro{rules}, each of which
specifies under what conditions $C$ subject $S$ is allowed or denied
to perform action $A$ (e.g., read) on certain object (i.e., resources) $O$ in a given system.

More than one rule in a policy may be applicable to a given request.
A \Intro{combining algorithm} is used to combine multiple
decisions into a single decision. There are four standard
combining algorithms. The \Intro{deny-overrides} (\Intro{permit-overrides}) algorithm returns \CodeIn{Deny} (\CodeIn{Permit}) if any rule
evaluation returns \CodeIn{Deny} (\CodeIn{Permit}).
%The
%\Intro{permit-overrides} algorithm returns \CodeIn{Permit} if any
%rule evaluation returns \CodeIn{Permit}. 
%Otherwise, the algorithm
%returns \CodeIn{Deny}.
The \Intro{first-applicable} algorithm returns what the
evaluation of the first applicable rule returns. The
\Intro{only-one-applicable} algorithm returns the decision of the only
applicable rule if there is only one applicable rule, and returns
error otherwise.

% A policy may have more than one XACML rule.

Figure~\ref{fig:example} shows an example policy specified
in XACML. Due to space limit, we describe only
one rule in the policy in a simplified XACML format. 
%Note that we simplified XML formats to reduce
%space for this example.
Lines 3-12 describe a rule that \CodeIn{borrower} is permitted to \CodeIn{borroweractivity} (e.g., borrowing books) \CodeIn{book} in \CodeIn{working days}.


\Comment{
\subsection{Regression Testing}
Software testing \cite{Myers:1979:AST:539883} refers to the activity of generating Tests Cases to verify the conformity of output results provided by a 
program to the expected output that meets its functional and non functional requirements. With the increasing complexity of software systems, 
this activity is gaining more and more interest in the research field and aiming to establish a trade-off between cost, time and quality. 
%%%%link%%%%

Software is subject to changes that occur at the design stage or in later stages at the deployment or maintenance phases. These changes are 
usually supposed to meet changes in the requirements or to overcome errors that can be detected in later stages of software life cycle. 
Regression testing refers to the research field that is interested in retesting the system to verify that the new changes have not altered 
the initial system behavior. As highlighted by Rothermel et al. in \cite{Rothermel:1996:ART:235681.235682}, regression testing is defined like the 
following: 
``Given a program $P$, a modified version $P'$, and a set $T$ of test cases used previously to test $P$, regression analysis and testing 
techniques attempt to make use of a subset of $T$ to gain sufficient confidence in the correctness of $P'$ with respect to behaviors from $P$ retained 
in $P'$''.

The main objectives of regression testing is to reduce the cost of rerunning initial test cases and to maximize the capability of 
selected test cases to detect potential faults induced by changes.
To the best of our knowledge, there is no previous research work on regression testing that considers policy changes in policy-based software systems.

\Comment{ 
The global scenario that illustrates regression testing process for such systems is presented in Figure~\ref{fig:process}.
In the scenario, our test-selection technique identifies the changed policy behaviors (
i.e., rules impacted by policy changes)
 between a policy $P$ and its modified version $P'$ and selects only the portion of test cases $T'$ to reveal different behaviors
impacted by policy changes. If there exists changed policy behaviors not-covered with $T'$, our test augmentation technique generates additional test cases $T''$  to achieve 100\% coverage of the changed policy behaviors.
}

%In the next section, we present our three test selection techniques and our test augmentation technique.
%Moreover, a test selection algorithm is \CodeIn{safe} if, under certain well-defined conditions, the algorithm
%include the set of every fault-revealing test case $F$ $\subseteq$ $T'$ that would reveal faults in the modified version.
%In order words, in \CodeIn{safe} regression algorithm, fault detection capabilities of executing selected test cases is equivalent to
%that of executing all of test cases.
%Two criteria are used to evaluate test selection algorithms~\cite{willmor05:safe}.
%The first one is \emph{inclusiveness}, which is the extent to include
%all necessary fault-revealing test cases in $T'$.
%The second one is \emph{precision}, which is the extent to eliminate
%non-fault-revealing test cases in $T'$.


In this paper, we classify system test cases into two types. %illustrated in Figure~\ref{fig:systemtestcases}.
The first one is a set of functional system test cases, which
are produced based on functional requirements. However, these functional
system test cases are not involved in testing security requirements (e.g., triggering application code to generate
and evaluate requests against a policy under test).
The second one is a set of security system test cases.
Different from the functional system test cases,
these security system test cases
involve in triggering application code to generate
and evaluate requests against a policy under test.
\Comment{ Moreover, security system test cases may include test oracles
to determine whether program behaviors interacting with a policy
are correct.}


%\FixJeeHyun{The figure \ref {} illustrates the overall scenario of regression testing applied to policy-based software systems\\
%ADD schema}
%
%
%\begin{figure}[t]
%    \centering
%        \includegraphics[width=3.0in]{regressiontesting.eps}
%       \vspace{-4pt}
%    \caption{\label{fig:process}Regression Testing Process}
%   \vspace{-10pt}
%%    \vspace{+3pt}
%\end{figure}
%\begin{figure}[t]
%    \centering
%    \vspace{+5pt}
%        \includegraphics[width=2.5in]{systemtestcases.eps}
%       \vspace{-4pt}
%    \caption{\label{fig:systemtestcases}System test cases}
%   \vspace{-10pt}
%    \vspace{+3pt}
%\end{figure}

%\subsection{Definitions}
%
%Security policy testing (SP testing): it denotes the activity
%of generating and executing test cases that
%are derived specifically from a SP. The objective of
%SP testing is to reveal as many security flaws as
%possible.
%Test case: In the paper, we define a test case as a triplet:
%intent, input test sequence, oracle function.
%
%To help answer these questions, we collect several metrics to
%to show effectiveness and efficiency of our test selection techniques and
%our test augmentation technique. 
%The following metrics are
%measured for each subject under test interacting with each modified policy
%and each technique.
%\begin{itemize}
%%	\item \textit{Selected test case count}.  The test count is the size of the request set or
%%the number of tests generated by the chosen test-generation
%%technique. For testing access control policies, a test is synonymous with request
%	\item \textit{Functional system test cases.} 
%	The test cases exercise functional requirements of a software system.
%	By opposition with security system test cases, we call these test cases
%	
%	System/functional testing . the activity which consists
%of generating and executing test cases which are
%produced based on the uses cases and the business
%models (e.g. analysis class diagram and dynamic
%views) of the system. By opposition with security
%tests, we call these tests functional.
%
%
%	 Given a policy and its modified
%	policy, the test reduction percentage is the number of selected test cases for regression testing divided by number of security test cases.
%		\item \textit{Modified policy behavior count.}  Given a policy and its modified
%	policy, the modified policy behavior count is the number of impacted rules by policy changes.
%	\item \textit{Modified policy behavior coverage count.}  Given a policy and its modified
%	policy, the modified policy behavior coverage count is the number of
%	impacted rules covered with existing test cases.
%	\item \textit{Modified policy coverage percentage.}  Given a policy and its modified
%	policy, the modified policy behavior coverage percentage is the modified policy behavior coverage count divided the total number of impacted rules.
%	\item \textit{Elapsed time.}  The elapsed time is time (measured in milliseconds) elapsed for each step during the test selection process.
%	\item \textit{Augmented test case count.}  The augmented test case count is the number of augmented test cases by each augmentation type.
%	
%\end{itemize}

}

